Eclipse WTP, JSF und JBoss

Heute mal ein klein wenig Ärger über Eclipse WTP. Offenbar verwendet das Web Tools Project von Eclipse den Projektnamen als Präfix für die jeweilige Deployment-Einheit, also bei einem Projektnamen von "JSF - Übung 01" würde beispielsweise das Web-Archiv "JSF - Übung 01.war" heißen. Dass damit nicht alle Application-Server klarkommen, kann man nicht nur vermuten...

Nun ja - während eine Tomcat 5.0-Runtime keine Probleme damit hat, verschluckt sich sowohl Tomcat 5.5 als auch ein JBoss 4.0.5 (der ja auch nur einen Tomcat 5.5 unter der Haube hat)
- das allerdings mit einer sehr "aussagekräftigen" Fehlermeldung:

java.lang.NullPointerException
   javax.faces.webapp.FacesServlet.init(FacesServlet.java:165)

Der Code an der Stelle greift während der Servlet-Initialisierung auf die LifecycleFactory zu:

lifecycle = lifecycleFactory.getLifecycle(lifecycleId);

Auch nicht besonders hilfreich beim Finden des eigentlichen Fehlers.

Nun ja - in diesem Thread im JSF-Forum von SUN fand ich einen Hinweis auf Spaces im Dateinamen und überprüfte diesen Verdacht.
Siehe da - er bestätigte sich und nach Behebung dieses "Bugs" in meinem Projektnamen funktionierte es auch unter JBoss und Tomcat 5.5...

Java Exception Architektur

Nach dem Studium eines interessanten Artikels auf dev2dev habe ich mir nun meine eigene Meinung zum Exception Handling in Java-Anwendungen gebildet.
Vielerorts wird ziemlich kontrovers über dieses Thema diskutiert und hier ist nun mein Beitrag dazu.

Die grobe Unterteilung in Checked und Unchecked Exceptions lässt sich relativ gut auf die Schnittstellen und technischen Rahmenbedingungen innerhalb einer Java EE Anwendung abbilden.

Checked Exceptions

Dieser Typ von Exceptions - also alle direkten Ableitungen von java.lang.Exception - sollte nur dann Verwendung finden, wenn sie zu der definierten Schnittstelle einer Methode gehören. In diesem Fall stellen sie ein erwartetes Fehlverhalten der betreffenden Methode dar, welches aus der Implementierung und den aktuellen Eingabeparametern der Methode resultiert.
Diese Exceptions werden mittels throws an der Signatur der Methode spezifiziert und repräsentieren negative Ergebnisse der Methode, die vom Aufrufer behandelt werden MÜSSEN. Wichtig dabei ist also, dass der Aufrufer mit diesen negativen Ergebnissen der Methode auch umgehen KANN.
Ein populäres Beispiel ist eine AccountOverdrawException einer Methode zum Abheben von einem Konto. Die Möglichkeit des Auftretens des Fehlers "Konto ist überzogen" wird hier bereits durch die Methodensignatur kommuniziert:

public void withdraw(Account account, double amount) throws AccountOverdrawnException, ... {
...
}

- these failures have to be handled by the caller - so there must be something the client can do to recover from this situation

Unchecked Exceptions

Unerwartete Fehlersituationen, die Situationen repräsentieren, die völlig unabhängig von der internen Implementierung bzw. den Eingabeparametern einer Methode sind, sollten als Unchecked Exceptions - also direkte Ableitungen von java.lang.RuntimeException - implementiert werden.
Beispiele hierfür sind Fehler in der Software oder in der Ausführungsumgebung, z. B. Datenbankfehler.

Fazit

Als Fazit kann man gut eine Richtlinie aus Sun's Exception Tutorial verwenden:

If a client can reasonably be expected to recover from an exception, make it a checked exception.
If a client cannot do anything to recover from the exception, make it an unchecked exception.

Weitere Meinungen und Referenzen

Alan Griffiths hat seine eigenen Erfahrungen, die sich wie folgt zusammenfassen lassen: Unchecked Exceptions sollten sparsam eingesetzt werden...

Bruce Eckel ("Thinking in Java") steht auf dem Standpunkt: Checked Exceptions are not needed at all - auch eine interessante Diskussion!
Sein Fazit: gar keine eigenen Checked Exceptions verwenden und alle Checked Exceptions des JDKs bzw. von Dritthersteller-Bibliotheken mit einem speziellen ExceptionAdapter wrappen, der sich von java.lang.RuntimeException ableitet.

Dieser Standpunkt hat auch etwas für sich - als Beispiel sei hier die SQLException als Checked Exception der JDBC API zu nennen:
Wenn der Datenzugriffscode z. B. sich zu etwas entwickelt, das KEINE Datenbank (sondern z. B. einen Web-Service) benutzt, besteht das Problem, die eigene Schnittstelle zur Persistenzschicht ändern zu müssen, wenn dort bisher die SQLException einfach nur propagiert wurde. Wenn diese Checked Exception in etwas Allgemeineres - oder gar eine Unchecked Exception umgewandelt würde, könnte die Anpassung der eigenen API vermieden werden.

... und nun in Deutsch...

Damit mein Blog etwas produktiver wird, habe ich mich entschlossen, in meiner Muttersprache zu bloggen - ab sofort also in Deutsch...